I know this is out of scope, but the error should be about assignment mismatch.

package main

func foo() ([]int, []string) {

	return []int{1, 2, 3}, []string{"a", "b", "c"}
}

func main() {

	r1 := &foo()

}

// Error:
// cannot take address of foo<VPBlock(3,0)>():

This one is actually in scope; you're right that in this case it doesn't make sense for the addressability error message to supersede the results mismatch. In fact, the addressability message doesn't make sense because it is trying to take the address of multiple values. Addressed this here: 3f4f1b6

For the cases like this where the addressability is assigned during preprocess, what do you think about moving Addressability as an attribute?

The reason why I say this is that we currently have a bunch of information which is not actually persisted, but recovered by using Preprocess. The Expr types here contain in their struct only information which comes directly out of the AST representation; not from preprocessing. I'm not entirely sure of why it's designed this way; but I think for consistency we should maintain the split between "preprocessed information" in Attributes, and AST information in the struct themselves.

If addressability is an attribute, I also wonder if there's a way to remove the specific type and turn this into Addressable() bool instead.

I don't think there is a good way to make an Addressable() bool method due to reasons I outlined in responses to other comments -- there are one or more cases where addressability is not applicable so the preprocessor should handle execution as usual. That being said, while many other attributes apply only exist some of the time, the Addressability attribute exists for all addressable expressions -- everywhere it appears. For ease of access, I'd prefer not to make this an attribute.